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ABSTRACT 


A  rcstructurablc  computer  system  offers  the  user  an 
evolutionary  approach  to  the  design  and  use  of  computer  systems. 
To  support  this,  a  unified  approach  is  proposed  in  this  report. 
A  meta  machine  and  its  environment  are  described  which  provide 
the  ability  to  treat  a  macromodular  description  of  a  system  as 
a  program  to  be  ..xccuud  or  as  a  set  of  specifications  from 
which  the  system  may  be  directly  implemented  in  macromodules. 
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A  UNIFIED  APPROACH  TO  THE  DESIGN 
AND  USE  OF  RESTRUCTURABLE  COMPUTER  SYSTEMS: 
THE  META  MACROMODULE  MACHINE 

1.  INTRODUCTION 


The  macromodular  project  at  Washirtgton  University  is  i  particular  implementation  of  a  class  of 
computet  systems  which  are  resiructurable.' A  restructur^ble  computer  system  is  capable  of  a 
flexibility  in  hardware  that  has  long  been  possible  only  by  programming.  In  addition,  the  macromodula: 
concept  proposes  to  make  this  restructurability  available  to  the  user  without  '*quiting  him  to  be  concerned 
with  logically  irrelevant  engineering  details.  The  user  will  have  functional  units  of  the  nature  of 
registers,  adders,  subtracters,  etc., whose  electrical  and  timing  details  have  been  solved  for  him  by  tlie 
designers  of  the  macromodules. 

Although  several  computer  and  systems  designs  have  been  investigated  in  the  course  of  the 
of  the  research,  no  one  has  attempted  to  investigate  in  general  the  operating  environment  of  a  macro- 
modular  system.  In  particular,  the  support  necessary  to  achieve  the  smooth,  evolutionary  approach  to 
computer  design  that  macromodules  promise  has  not  yet  been  investigated.  This  repo.-t  identifies  the 
problems  associated  with  this  evolutionary  approach  and  proposes  specific  measures  to  support  it. 
The  unified  approach  of  the  title  reiers  to  the  ability  to  treat  a  macromodular  description  of  a  system  as 
a  piogram  to  be  executed  or  as  a  set  of  specifications  which  will  allow  the  user  to  directly  implement 
the  system  in  macroraodules.  Central  to  the  approach  is  the  concept  that  the  user-designer  may  choose 
to  implement  whatever  sections  of  the  design  he  wishes  and  leave  the  test  to  be  run  as  a  program . 
The  paper  includes  an  investigatior,  in  detail,  of  that  which  is  necessary  to  implement  the  unified 
approach. 
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2.  THK  PROBLEM  AND  A  PROPOSED  SOLUTION 


2.1  RESTRUCTURABLE  COMPUTER  SYSTEMS 

The  advantages  of  restnicturable  computer  systems  have  been  well  dociimeiited  in  the  literature.'-^ 
The  ability  to  easily  construct  special  and  general  purpose  co'^nuters  whose  design  is  tailored  to  a 
single  class  of  problems  is  a  most  desirable  goal.  Indeed  the  ecc  :umy  of  specialization^  may  far  outweigh 
the  economy  of  scale  which  has  been  so  completely  taken  as  an  absolute  truth  in  the  computer  field. 

2.2  MACROMODULAR  SYSTEMS 

The  macromodular  project  at  Washington  University  is  an  investigation  of  a  concept  of  restructurable 
computer  systems.*  For  the  present,  macromodules  consist  of  a  set  of  relatively  simple,  easily  inter¬ 
connected  modules  from  wh.ch  working  systems  can  be  easily  assembled.  The  modules  are  functionally 
large  enough  to  reduce  logical  detail  by  a  significant  amount  and  are  relatively  easy  'o  understand  and 
assemble.  The  modules  are  directly  combined  to  form  larger  structures  by  straightforward  mechanical 
assembly  and  easily  connected  cables.  They  have  been  der.igned  so  that  the  assembling  of  these  units 
into  working  systems  presents  no  logically  irrelevant  details  such  as  those  related  to  circuit  loading, 
waveform  deterioration,  signal  propagation  delay,  and  power  supply  interaction.^  regardless  of  the  sire 
and  complexity  of  the  system. 

2.3  AN  OPERATING  ENVIRONMENT  FOR  MACROMf'-aULAR  SYSTEMS 

While  several  computer  systems  have  been  designed  utilizing  macromodules, ^'*'*'*  very  little 
investigation  has  been  done  concerning  the  operating  environment  and  the  problems  that  tlie  great 
generality  ct  lestructurable  computer  systems  pose.  The  reason  is  understandable:  the  lack  of  precedent 
in  the  field  tends  to  overshadow  all  else.  A  very  reasonable  approach  is  to  adopt  a  wait  and  see 
attitude  with  regard  to  any  conventions  or  aids  relating  to  the  use  of  macromodules. 

It  is  interesting  to  note  that  most  of  the  systems  which  have  been  designed  have  relied  on  a  fixed, 
programmable  computer  for  support  of  the  macromodular  machine.  In  some  cases*-*  the  support  required 
is  merely  a  replacement  for  those  mecromodules  which  have  not  yet  been  designed  i.e.  Input-Output 
while  in  other  cases*  the  supporting  machine  is  used  to  perform  some  of  the  operations.  Ilic*-comment  has 
generally  beer-,  made  co.iceming  macromoduies  chat  it  is  difficult  to  see  a  situation  in  which  some  fixed 
computer  would  not  be  required  to  give  operating  and  programming  support  to  the  collecLivu  of  macro- 
modules. 

2.4  PROBLEMS  INTRODUCED  BY  MACROMODULAR  SYSTEMS 

There  are  several  problems,  other  than  the  obvious  one  of  programming  support,  which  are  inherent 
in  the  macromodular  toncep..  For  example,  one  may  not  wish  to  actually  implement  all  of  a  design  in 
macromodular  hardware  at  any  one  time.  There  is  a  general  reason  for  this  in  that  the  evolutionary 
approach  to  the  design  of  a  suitable  configuration  of  macromoduies  is  certainly  desirable.  This  is 
often  cited  as  an  advantage  of  restructurable  computer  systems,  but  it  does  not  automatically  follow. 
Theie  may  be  other  reasons  for  not  actually  constructing  the  complete  system.  For  example,  there 
might  be  a  problem  with  inventory  if  several  users  arc  sharing  a  common  inventory  of  macromoduies. 


Finally,  there  appears  to  be  no  leal  reason.  c>.cept  for  absolute  necessity,  for  actually  building  special 
configurations.  The  necessity  almost  always  concerns  time  in  bcjt  real-time  an',  si'aight  compulation 
situations. 

Anoti.er  problem  is  tha  if  one  wants  to  make  a  change  in  an  already  working  system,  the  wires 
have  to  be  changed.  It  is  prcb^'  ly  not  feasible  to  make  a  copy  of  the  frame  wiring  so  it  will  be  difficult 
to  back  up  from  changes  which  have  been  made  but  da  not  yet  work.  Analog  computers  !  ave  removable 
patch  panels  for  interconnection  of  processing  elemenfs.  However,  these  panels  restrict  the  number  and 
types  of  connections  which  can  be  made.  Macromodules  require  the  possible  interconnection  of  any 
module  to  any  othei  module;  a  feat  not  possible  with  analog  computer  patch  panels.  To  further  complicate 
matters,  the  physical  arrangement  may  have  cha''ged  due  to  the  addition  of  new'  modules.  It  will  also  be 
very  difficult  to  make  a  quick  change  to  sec  what  effect  it  has  on  the  operation  of  the  system.  This  is 
a  very  important  problem  and  one  which  has  been  somewhat  overlooked  until  now. 

Finally  there  is  the  problem  of  simulatioti.  A  natural  tool  to  use  in  an  area  of  hardware  development 
is  functional  simulation.  Simulation  allows  one  to  largely  correct  a  design  before  building  '  and  to  try 
out  proposed  changes.  With  simulation  comes  a  very  large  overhead.  It  seems  difficult  to  improve  the 
approximately  1000  to  1  ratio  in  time  with  any  of  the  simulation  efforts  to  date.®'’-’®  The  1000  to  1 
figure  is  actually  quite  optimistic  because  it  is  quite  easy  to  increase  the  ratio  several  times  by 
inefficient  code  or  increased  power  and  flexibility  of  the  simulation  effort. 

2.5  A  UNIFIED  APPROACH 

The  ur  'fied  approach  in  this  report  refers  to  the  capability  of  treating  a  description  of  a  macro- 
modular  system  as  a  program  which  may  be  executed  or  as  a  set  of  specifications  which  will  allow  the 
user  to  directly  implement  the  system.  It  is  proposed  in  support  of  the  unified  tipproach,  that  an 
essentially  fixed  machine  be  constructed  whose  primarv  function  is  to  route  conuol  and  data  transfer 
operations  as  specified  by  a  description  of  a  macromodular  system  so  as  to  mediate  between  actually 
implemented  functions  and  those  which  must  be  simulated.  This  function  defines  a  class  of  machines; 
however,  enough  of  the  details  of  the  external  appearance  required  of  these  machines  will  be  defined 
that  this  class  is  reduced  to  a  specific  mac.Sine  for  the  purposes  of  this  paper.  .Although  an  analogy 
between  this  description  and  a  program  has  been  introduced  here,  the  reader  should  be  cautioned  not  to 
expect  this  meta  macromodiile  machine  M4  to  have  the  typical  order  code  organization  of  conventional 
stored  program  machines.  Obviously,  the  M4  must  have  suitable  features  to  enable  it  to  interact  with 
the  external  macromodular  structures.  A  common,  machine-readable  description  of  a  macromodular 
system  can  nov.'  function  as  a  program  for  the  meta  machine  or  as  a  specification  for  actually  constructing 
all  or  parts  oi  the  system.  Functions  which  must  be  simulated  ate  identified  as  intemally  implemented 
functions  while  those  actually  constructed  from  rcacromodules  are  called  e'^ternally  implemented  functions. 
With  proper  design  it  is  possible  to  switch  actively  between  internally  and  externally  implemented 
functions  at  the  lowest  possible  level  of  macromodular  primitive  operations. 

Figure  1  .shows  the  several  components  of  this  unified  approach.  The  maciomodular  component 
consists  of  the  user-designed  functions  which  arc  implemented  by  macromodules.  This  component  is  not 
discussed  in  this  paper.  The  interface,  which  partly  overlaps  the  macromodular  component,  permits 
communication  between  externally  and  internally  implemented  macromodular  functions.  The  overlap  area 
consists  of  the  conventions  which  must  be  observed  in  implementing  the  macromodular  component  in 
order  for  it  to  wotk  with  the  interface.  The  entire  interface  is  specified  in  detail  in  Sectior  4. 

The  M4  control  permits  internally  implemented  macromodular  functions.  'T'he  macromodule  simulation 
component,  which  is  only  a  part  of  the  M4.  provides  the  capability  to  perform  internally  implemented 
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THE  COMPONENTS  OF  THE  UNIFIED  APPROACH 


Figure  1 
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macomodular  functions.  The  M4  control  plus  those  areas  of  the  macromo  le  simulation  which  directly 
interact  with  it  are  discussed  in  Section  3.3.  The  details  of  simulation  oi’  macromodules  by  hardware  or 
software  is  not  of  great  interest  in  this  report,  but  some  considerations  are  presented  in  Section  3.4  and 
one  particular  scheme  is  discussed  in  Appendix  6.4. 

Finally,  the  details  of  the  general  purpose  computation  component  are  beyond  the  scope  of  this 
report;  however  general  comments  regarding  this  component  appear  throughout  the  report, 

2.S  ADVANTAGES  OF  THE  UNIFIED  APPROACH 

.  ne  lack  of  irrelevant  engineering  detail  required  in  the  design  of  macromodular  systems  puts  a 
description  of  such  a  system  on  the  level  of  assembly  language  programming.  The  description  can  ignore 
such  details  as  actuci  physical  arrangement  of  modules  and  wire  placement  and  leave  them  for  the 
construction  phase.  This  means  that  the  description  and  program  for  the  M4  can  be  truly  identical  in  all 
respects.  The  proposed  meta  machine  approach  requires  that  only  those  critical  portions  of  the  design 
need  to  be  implemented  in  hardware.  Also,  proposed  changes  may  be  made  to  the  programmed  structure, 
checked  out,  and  only  then  built  with  actual  macromodules. 

Initial  studies  indicate  that  the  meta  machine  can  typically  simulate  non-memory  operations  at  a 
ratio  of  100  to  1  in  time  and  that  SO  to  1  is  perfectly  feasible.  See  Appendix  6.2  for  supp-^rting  calcu¬ 
lations.  Memory  operation  .<mes  approach  to  a  1  to  1  ratio  between  externally  and  internally  ii..oleme^ted 
functions.  The  meta  machine  can  also  be  used  to  provide  prograr.vaing  support  fc  the  macromodular 
configuration  and  in  any  of  tt<e  supporting  roles  which  require  a  stored-program  compoie  .  Tinal'y,  it  can 
be  seen  that  the  meta  niachine  can  itself  be  constructed  from  mdoromoduLss.  We  call  th>s  the  macro- 
modular  meta  macromodule  machine  3'6.  Of  course  in  tie  Fna!  sense,  the  meta  machine  should  be 
constructed  in  a  fixed  form  except  for  certain  sections. 

Because  the  M4  is  essentially  fixed,  a  compiler  for  higher  level  languages  can  be  written  for  it. 
Then,  these  languages  could  be  used  for  macromodular  descriptions  although  because  of  efficiency  of 
equipment  considerations  their  results  would  probably  only  be  executed  internally  to  the  M4.  If  this 
higher  level  language  work  were  done  with  the  unified  approach  in  mind,  it  would  be  possible  to  describe 
the  solution  algorithm  in  these  higher  level  languages  in  a  c./mpatibie  manner,  particularly  if  operating 
efficiency  could  be  sacrificed.  See  Appendix  6.3  for  an  example 

2.7  PROBLEMS  ASSOCIATED  WITH  THE  UNIFIED  APPROACH 

The  use  of  a  meta  macromoduH  machine  is  not  without  problems.  The  uistin'tion  between 
hardware  and  p'ogram-implemented  structures  must  be  at  the  lowest  possible  level.  This  means  that  it  is 
possible  to  impl.'men.  one  register,  or  one  add  operation,  or  even  a  single  control  branch  as  hardware 
in  the  operating  ei,vironment  envisaged  here. 

Another  problem  occurs  with  the  basic  unit  of  storage,  the  register.  It  is  impossible  for  a  register 
to  exist  both  as  actual  h.^rdware  and  simultaneously  as  a  storage  location  within  the  memory  of  the  meta 
machine  because  of  the  problems  of  niaintaining  both  images.  Once  a  register  exists  in  macromodular 
form,  all  references  to  it  must  refer  to  the  actual  register. 

A  problem  also  exists  in  the  control  area.  Naturally  a  means  must  be  provided  for  control  to  cross 
the  boundary  between  haidware  and  program  in  both  directions.  This  is  reasonably  straightforward  until 
we  consider  concurrent  processes.  Concurrent  processes  must  be  executed  in  an  equivalent  sequential 
order  within  the  meta  machine  and  any  implemented  in  iriacromodules  must  be  executed  in  parallel  if 
at  all  possible. 
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Naturally  the  meta  machine  n.nst  be  capable  of  lepresenting  macromodular  systems  subject  to 
constraint  of  indefinite  extension.  In  general  this  nust  be  accon;plishcd  without  rescrt  to  changing 
the  meta  machine. 
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3.  DISCUSSION  OF  THE  META  MACROMODULE  MACHINE 


3.1  INTRODUCTION  TO  THE  DISCUSSION  OF  THE  META  MACROMODULE  MACHINE 


In  this  section  the  organization,  operation,  and  implementation  of  the  meta  macromodule  machine 
are  discussed.  The  basic  requirement  of  the  meta  machine  is  that  it  be  able  to  route  control  and  data 
transfer  operations  and  communicate  with  external  macromodular  structures  as  specified  by  a  description 
of  a  macromodular  system.  Questions  of  the  operations  of  the  M4  ate  required  to  support  the  unified 
approach  ate  discussed  in  terms  of  macromodular  designs. 

3.2  ORGANIZATION  OF  THE  META  MACROMODULE  M.ACHINE 

The  most  obvious  organization  of  the  M4  is  as  a  basic  computet  whose  order  code  consists  of 
the  primitive  operations  available  with  macromodules  plus  control  and  data  options  which  permit 
communication  with  external  macromodules.  A  suitable  programming  language  could  then  be  de, 'eloped 
to  accom.pany  this  machine.  For  example,  any  of  thr  functional  macromodular  simulation  languages 
could  provide  a  model  for  this  development,®'’*’^  or  see  A^^pendix  6.4  for  a  specific  example. 

This  approach  is  less  than  satisfactory,  however,  because  a  given  macromodule  can  often  be  used 
in  several  different  ways.  For  example,  a  data  gate  mm  ■'omodule  may  be  used  to  transfer  data  into  a 
macromodular  register  or  to  indicate  data  to  be  stored  into  a  macromodular  memory.  Indeed,  it  is  possible 
for  a  single,  multiple-length  data  gate  to  perform  both  of  these  operations  simultaneously.  This  is  in 
contradiction  to  the  simulator  languages  which  treat  these  as  two  distinctly  different  operations  because 
of  the  lack  of  context  dependence  in  such  languages.  Also,  should  new  slightly  different  macromodules 
be  designed,  it  is  just  possible  that  the  funciional  language  descriptions  could  not  handle  such  new 
modules. 

The  requirements  imposed  by  command  oriented  languages  are  awkward  when  compared  to  the  usual 
mac.-otv'ndular  design  process.  A  macromodular  system  is  completely  described  by  a  picture  of  the 
connet  livity  of  data  processing  operations  and  a  flowchart  of  the  control  operations  which  are  performed. 
This  rotation  is  described  as  a  uniform  and  consistent  scheme  of  notation  in  Appendix  6.1.  A  fat  mote 
direct  approach  would  be  to  find  some  suitable  way  to  enter  the  diagrams  and  flowcharts  into  the  meta 
machine  and  have  the  execution  diiec'iy  or'cnted  to  the  actual  internal  operations  of  the  macromodules. 
Because  of  the  above,  all  of  the  material  in  this  report  is  presented  independent  of  any  actual  machine 
langii.ige  code  for  the  M4. 

3.3  OPERATIONS  OF  THE  META  MACROMOC  JLE  MACHINE 

Now  the  interna!  operations  of  the  meta  machine  are  aescribed  which  are  required  to  support 
externally  implemented  macromodular  functions.  The  operations  which  must  be  supported  ate  the  transfer 
of  data  in  both  directions  across  the  VH-external  interface  a.id  the  ability  of  the  M4  to  generate  and 
accept  macromodular  control  signals  "^he  external  aspect  of  these  operations  is  discussed  in  Section  4. 
For  the  present,  we  are  not  concerned  with  the  rest  of  the  M4. 

It  is  assumed  that  registers  and  controi  points  are  properly  marked  in  the  description  so  that  the  M4 
may  m.ake  the  decision  between  external  or  internal  implementation.  For  an  example  of  a  suggested 
symbolic  marking  technique,  see  Appendix  6.1.  A  more  detailed  possibility  for  the  marking  is  presented 
in  Appendix  6.4.  For  external  implementation,  a  number  must  be  associated  with  each  unique  register 
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and  control  point  to  serve  as  a  reference  for  the  purpose  of  crossing  the  interface  between  the  M4  and 
externally  implemented  functions.  It  is  possible  that  extra  memory  will  be  required  in  the  M4  to  provide 
space  for  this  marking  data,  but  this  must  be  accepted  in  an  approach  with  as  much  generality  as  is 
being  proposed  here.  This  marking  function  must  be  a  cential  part  of  the  Vi4  design  so  that  all  irternal 
operations  may  make  use  of  it. 

3.3.1  DATA  FETCH  FROM  EXTERNAL  REGISTER 

Figure  2  shows  the  operations  necessary  to  *'ctch  the  contents  of  an  externally  implemented 
macvomodular  register.  The  number  of  the  external  register,  which  is  available  as  a  consequence  of 
the  operation  of  the  M4,  is  first  transferred  into  the  External  Register  Select  Register.  Control  then 
exits  to  the  external  environment  and  fetches  these  data  as  shown  in  Section  4.2.  After  the  data  have 
been  made  available  tc  the  M4.  control  returns  to  the  M4  for  processing  of  the  data.  Note  that  only  one 
such  operation  is  executed  at  one  time  because  as  far  as  the  M4  is  concerned  all  data  are  transferred 
sequentially  in  12-bit  segments. 

3.3.2  DATA  STORE  >NTO  EXTERNAL  REGI.STER 

Figure  3  shows  the  internal  operations  required  to  store  data  into  an  externally  implemented 
macromodular  register.  t>.e  operations  are  analogous  to  those  of  Section  3.3  I  except  that  control  exits 
and  returns  at  a  different  set  of  control  points. 

3.3.3  SOME  INTERNAL  CONTROL  OPERATIONS 

Before  discussing  control  signal  generation  and  return,  it  is  necessary  to  discuss,  in  general 
terms,  the  internal  M4  operations  required  to  start  the  next  internally  specified  macromodular  function. 
Figure  4  shows  the  operation  when  strictly  sequentia.  functions  are  specified. 

If  the  next  function  is  internally  implemented,  it  is  decoded  and  executed  in  a  form  similar  to  the 
typical  stored-program  computer.  If  the  function  is  externally  implemented,  an  external  control  signal  is 
generated  as  explained  in  Section  3.3.4  and  then  control  enters  a  wait  status  Central  to  the  control 
structure  of  the  M4  is  a  stack,  which  can  be  either  first  in-first  out  or  last  in-first  out,  which  is  used 
remember  control  operations  which  cannot  immediately  be  executed.  Returning  external  control,  as  will 
be  shown  in  Section  3.3.5,  forces  a  pointer  to  the  next  internal  function  to  be  perfonned  into  the  control 
stack.  The  wait  status  therefore  simply  causes  a  pause  in  opera'>on  until  a  pointo^r  becomes  available 
at  the  top  of  the  stack. 

Concurrent  control  requires  that  at  least  two  functions  be  performed  at  the  same  time.  This  two- 
way  splitting  or  branching  must  be  capable  of  operation  for  all  combinations  of  external  and  internal 
functions  specified  as  the  branch  operations.  Also,  it  is  required  that  all  concunem  sequences  which 
are  externally  implemented  be  truly  concurrent  with  each  other  and  with  internally  implemented  functions. 
Finally,  it  is  required  that  internally  implemented  functions  are  executed  in  correct  sequential  order  even 
if  concurrent  processing  is  indicated.  Figure  S  shows  the  design  for  initiation  of  concurrent  control. 

3.3.4  EXTERNAL  CONTROL  OUTPUT 

Figure  6  shows  the  design  for  generation  of  external  control.  Concurrent  operations  are  possible; 
therefore  the  rendezvous  is  used  to  protect  the  operation  of  storing  a  new  control  ..cqiience  number. 
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The  dot  by  ont  of  llie  rendezvous  inputs  indicates  that  the  rendezvous  is  preset  with  that  input  active. 
Note  that  the  returning  control  signal  External  Control  Started  indicates  only  t'.at  the  externally  imple¬ 
mented  sequence  has  been  started  and  a  nev  sequence  number  can  be  loaded,  not  that  the  external 
control  sequence  has  actually  been  completed. 

3.3.5  EXTERNAL  CONTROL  RETURN 

Figure  7  shows  the  design  for  the  M4  operations  which  process  external  control  sequence  returns. 
The  interlock  is  required  because  control  returns  occur  asynchronously  with  respect  to  other  M4  oper¬ 
ations.  The  M4  memory  must  contain  a  ‘able  which  relates  returning  control  sequence  numbers  to  the 
place  in  the  description  where  internally  implemented  functions  are  t».  be  resumed.  The  pointers,  when 
read  from  memory,  are  placed  into  the  control  stack  where  they  are  eventually  read  and  used  by  the  M4. 

3.4  IMPLEMENTATION  OF  THE  META  MACROMODULE  MACHINE 

This  report  has  intentionally  remained  gent  al  and  has  not  specified  any  particular  implementation 
of  the  M4.  In  this  section  some  comments  are  made  concerning  several  possible  implementations. 
Each  implementation  has  its  own  particular  characteristics  which  may  indicate  which  implementation 
would  be  better  for  a  particular  application. 

3.4.1  MACROMODULAR  META  MACROMODULE  MACHINE 

The  most  obvious  implementation,  in  macromodules,  is  described  in  detail  elsewhere' '  and  is 
summarized  in  Appendix  6.4.  This  implementation  is  flexible  in  that  newly  defined  macromodules  can 
be  added  to  the  meta  machine  at  the  cost  of  changing  the  internal  operations.  Of  course,  if  the  set  of 
macromodules  is  closed,  then  a  considerable  overhead  is  inherent  in  the  design  using  macromodules. 
Note  that  a  class  of  instructions  which  ate  not  macromodular  operations  must  exist  for  this  machine. 
This  is  necessary  to  control  input-output  devices  which  make  the  machine  capable  of  general  support 
of  macromodules. 

This  implementation  represents  an  extreme  in  the  continuum  of  M4  implementations;  it  combines 
maximum  hardware,  ease  of  interface  with  external  macromodules,  maximum  speed  of  simulation,  c.nd 
minimal  space  requited  for  the  specification  of  the  macromodular  system.  The  speed  of  simulation  is 
essentially  the  100  to  I  figure  mentioned  as  an  upper  bound  on  speed  in  Section  2.6.1.  However,  maximum 
hardware  is  indicated  by  the  count  of  over  100  data  processing  modules  required,  makin;  this  at  least  a 
medium-sized  computer.  This  figure  does  not  include  any  general-purpose  computation  capability  or 
instructions  which  provide  general  programming  support;  however,  these  can  be  supplied  by  a  very 
elegant  method  discussed  in  Section  3.5.  A  single  4096  word  memoiy  macromodule  can  store  the 
specification  for  a  system  containing  approximately  500  macromodular  operations  and  100  register 
macromodules,  exclusive  of  any  memory  macromodules.  Typically,  u  small  computer,  such  as  a  PDP-5 
contains  approximately  40  macromodula’’  operations  and  6  register  macromodules  while  a  reasonably 
large  machine,  such  as  one  designed  for  linear  programming  problems,  might  have  approximately  300 
macromodular  operations  and  40  register  maciomodules. 

The  use  of  the  macromodular  meta  macromodule  machine  Mb  requires  that  the  user  have  available  a 
more  than  basic  inventory  of  macromodules  because  so  many  are  required  for  its  construction.  Its  use 
may  be  indicated  if  the  user  does  not  have  a  suitable  existing  computer  or  if  his  existing  computer  does 
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not  lend  itself  !o  interface  with  macromodules.  Of  course,  if  'he  user  does  not  have  the  talent  locally  to 
interface  his  exist'  %  machine  with  macromndules,  he  may  be  forced  into  this  implementation  if  he  wishes 
to  use  the  u,.  ..ed  'oach. 

3.4.2  FI.Xi-0,  MICRO-PROGRAMMED  MACHINE 

An  implementation  which  would  permit  the  addition  of  new  macromodule  types,  if  they  did  not 
vary  drastically  from  the  present  general  concepts,  and  yet  not  require  the  overhead  associated  with 
macromodules,  consists  of  a  fixed  machine  which  could  be  microprogramnicd  by  a  fast  read  only  memory. 
This  wo. '.d  be  a  most  attractive  implementation,  which  represents  an  intermediate  approach;  however, 
it  involves  the  designing  of  a  completely  new  computer  tailored  toward  simulation  of  maciomodules  and 
is  no;  Oiscussed  further  here. 

3.4.3  EXISTING  MACHINE 

Another  im,  lamentation  could  utilize  a  macromodule  simulation  program  on  an  existing  machine 
with  some  inierface  to  macromodules.  Such  an  effort  is  underway  in  the  laboratory  using  a  LINC 
(Laboratory  INstrument  Computer)  and  a  l.lNC-macr' module  interface  designed  by  an  associate  of  the 
autiior.'*  The  availability  of  the  LINC  software  which  includes  a  macro  facility  and  th.  ease  of  use  ana 
nrogramming  make  this  a  natural  choice.  Macromodule  simulation  exists  for  the  LINC,®  but  does  not 
embody  the  concepts  presented  in  this  report.  A  useful  aspect  of  'liis  type  of  implementation  is  'hat  the 
machine  language  of  the  existing  computer  can  be  used  whenever  such  use  is  more  appropriate  than  use 
of  the  macromodular  functions. 

The  requirement  that  the  user  construct  an  interface  between  his  existing  machine  and  macro¬ 
modules  is  one  of  the  most  important  characteristics  of  this  implenientai  5n.  It  does  not  seem  reasonable 
that  the  designers  of  iracromodules  solve  this  problem  except  by  providing  an  M4  macromodule.  This 
would  equ're  that  the  unified  appi<-ach  be  .  .r"*  the  standard  method  of  usinj  .lacro.Tiodules.  This  is  a 
very  real  possibility,  but  it  is  oo  early  in  .he  deveiopment  of  macromodules  to  do  more  than  speculate. 

If  the  user  chooses  this  implementation,  he  has  provided  himself  with  the  opposite  ;me  to 
that  discussed  in  Section  3.4.1.  This  implementation  provides  the  slowest  speed  of  si  lulation  combined 
with  a  minimum  amount  of  hardware.  Most  existing  small  computers  can  reasonably  be  used  in  this 
im.'plementation.  The  machine  should  be  capable  of  indefinite  extended  precision  arithmetic,  and  it  is 
convenient  if  it  is  a  12  bit  computer  Of  course,  the  user  also  has  all  of  the  features  of  thf  'o  nputer 
to  use  in  any  way  he  desires,  not  an  insignificant  advantage. 

O'l:  experiences  with  the  existing  LINC  macromodule  simulation  effort  indicate  the  parameters 
associated  with  this  implementation.  The  LINC  is  a  12  bit  computer  with  an  8  microsecond  cycle  time 
artd  2048  words  of  memety.  The  simulation  consists  of  a  set  of  macros  and  subroutines  assembled  to 
form  a  LINC  program  which  simulates  the  operation  of  a  macromodular  system.  The  simulation  soeed  .or 
12  bi*  ina  rromod'iile  operations  is  approximately  1300  to  1  as  compared  to  real  time  macromodular 
operations.  This  ratio  essentially  increases  linearly  vith  increased  length  of  simulated  macromodular 
operati.ons.  Systems  with  a  maximum  of  about  70  macromodular  operations  can  be  sim'jlated.  There  is 
a  direct  trade  between  number  of  simulated  registers  and  the  amount  of  simulated  memory.  However, 
systemr  with  only  70  operations  almost  never  invoi.'e  more  than  a  dozen  or  so  'egisiers  leaving  1024 
words  of  12  bit  memory  for  simulated  memory  macromodules.  If  an  interpretive  siniulatioi'  technique 
were  used,  the  number  of  simulated  operations  could  be  increased  with  the  penalty  of  decreasing  the 
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simulation  speed  by  a  factor  of  two  or  three.  Of  course,  a  2048  word  memory  is  extremely  modest  for 
even  the  typical  small  computers  currently  available. 

The  use  of  a  large  scale  computer  as  an  M4  has  not  been  considered  at  all  in  this  report.  Neither 
have  such  things  as  several  users  of  macrornodules  time  sharing  a  large  centrally  located  computer  been 
discussed  here.  It  is  felt  that  the  inclusion  of  these  topics  is  not  necessary  in  the  present  discussion. 

3.5  CONCLUSIONS 

Th's  secticn  has  discussed  the  meta  macromoduic  machine  which  supports  the  general  concept 
presented  in  this  report.  The  evaluations  of  alternate  organizations,  and  implementations  have  been  left 
to  future  research.  A  few  general  concluding  remarks  seem  to  be  in  order  at  this  time.  Possibly  the 
foremost  concern  in  the  specification  of  the  meta  machine  must  be  to  provide  a  machine  which  is  straight¬ 
forward  and  easy  to  use.  In  fact  it  should  be  possible  to  work  with  a  specification  of  a  macromodular 
system  for  execution  on  this  machine  directly  at  the  lowest  possible  level  and  to  by-pass  any  software 
support  for  some  operations.  This  is  a  particular  concern  cf  the  author,  but  the  serious  student  of 
computer  systems  will  see  that  a  great  a.:!ount  of  inefficiency  mav  result.  However,  it  must  be  remembered 
that  this  machine  is  intended  to  sim.ulate  hardware  operations  implemented  in  tern  s  of  macrornodules. 
Thus  a  description  of  1000  macrornodules  represents  a  large  hardware  system  while  a  nrogram  of  1000 
instructions  is  quite  a  small  system. 

The  foregoing  does  nomt  up  one  problem,  however,  that  exists  in  some  implementations  and 
organizations  of  the  M4.  If  the  M4  is  used  to  provide  general  sofware  support  tor  a  collection  i ' 
macrornodules,  then  some  programming  operations  are  needed.  The  organization  of  the  M4  may  not  b 
well  suited  to  programming  because,  for  example,  thv.  eed  not  be  any  addressing  or  indexing  flexibility 
provided.  Two  solutions  have  occurred  to  me  author.  One,  which  has  been  rejected  for  lack  of  elegance, 
would  provide  a  set  of  instructions  to  be  used  in  general  programming  of  the  M4.  A  nore  elegant  approach 
would  be  to  design  a  suitable  machine  in  terms  of  macrornodules  and  then  use  this  description  as  an 
interpreter  for  a  more  convenient  ma-'hine  language.  This  is  certainly  elegant  and  is  probably  feasible 
f'om  L  pragmadc  standpoint  because  a.ny  deniaitduig  .ompulaiions  would  be  perfonnec  oy  externally 
implemented  macromodular  operations.  Compilers  and  arithmetic  computation  oriented  machines  can  be 
designed  for  macrornodules®'*  which  could  then  be  efficiently  interpreted  by  a  macromodular  description 
in  the  M4. 
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4.  DISCUSSION  OF  EXTERNALLY  IMPLEMENTED  MACROMODULAR  FUNCTIONS 


4.1  INTROnUCTlON 

In  Section  3.3  the  use  of  externally  iniplemented  macromodular  registers  and  control  was  discussed 
in  connection  with  the  meta  maciomodule  machine.  In  this  section  the  conventions  are  uisct'ssed  which 
have  to  be  observed  in  implementing  external  functions  so  that  the  interface  between  them  and  M4  can 
be  standardized. 

;  4.2  REGISTER  GROUP 

I 

I 

!  Figure  8  shows  the  conventions  which  mujt  be  followed  to  permit  communication  between  external 

macomodu' ir  regir  ‘rs  and  M4.  The  dotted  line  indicates  the  physical  and  logical  boundary  of  the  M4. 
As  can  be  seen,  quite  a  large  number  of  macromodular  operations  must  be  implemented  by  the  user; 
however,  they  ate  quite  tegular  and  should  pose  no  problems 

The  example  shows  two  registers  implemented  cxiernully  to  the  M4.  One  register  is  12  bits  and 
the  other  is  24  bits  wide.  .Additional  data  processing  midules  ate  shown  on  the  registers  to  indicate 
that  the  registers  have  externally  implemented  transfers,  adders,  etc.,  which  Involve  them.  The  user 
must  number  the  registers  and  provide  the  proper  decoding  of  control  signals.  Because  only  12  bits  of 
data  can  be  transferred  at  one  time,  each  register  module  in  a  more  than  12  bit  register  must  be  considered 
as  a  separate  register  for  the  purpose  of  these  transfers. 

It  IS  the  responsibility  of  the  M4  to  establish  the  proper  data  out  signals  and  then  generate  a 
macromodular  control  signal  on  the  propei  line.  The  M4  processing  is  stopped  until  the  proper  return 
control  signal  is  received.  Because  of  tias  responsibility  on  the  part  of  the  M4,  the  user  actually 
has  very  little  to  be  concerned  with  whe.n  he  implements  the  required  operations. 

There  is  a  problem  in  that  the  overfiow  indication  cannot  be  transferred  from  ire  M4  to  the 
ex’er.  '.i  :.^vste:s.  Thstefe-.e  .s  no;  possible  to  perform  an  internal  operation  on  an  external  register 
and  then  have  the  correct  overflow  indication  transferred  to  the  register.  The  only  difficulty  is  that 
an  external  test  of  overflow  will  always  indicate  no  overflow  after  an  internal  operation.  This  is  a 
rather  small  point  but  still  one  which  the  user  must  remembei.  A  possible  solution  would  be  to  build  some 
macromodular  registers  which  are  capable  of  having  overflow  turned  on  by  a  control  signal.  However, 
from  the  pragmatic  point  of  view  it  is  felt  that  the  user  can  live  with  the  problem. 

If  there  .s  a  possibility  of  concurrent  operation  between  and  externally  i  plemented  functions, 
interlocks  must  be  placed  at  the  appropriate  places  in  th :  register  operations.  This  is  left  entirely  tc 
the  user  and  follows  directly  the  normal  macromodular  use  of  the  interlock. 

4.3  CONTROL  GROUP 

This  Section  discusses  the  conventions  required  of  externally  implemented  control  functions 
which  permit  a  standardized  interface  with  the  M4. 

4.3.1  CONTROL  OUTPUT  FROM  THE  M4 

The  M4  presents  a  data  word  which  represents  a  control  sequence  num.ber  which  must  be  decoded 
by  external  decoders.  Figure  9  indicates  the  necessary  operatioi.s.  A  requirement  of  external  control 
is  that  it  be  capable  of  concurrent  operation  with  internal  functions  of  the  M4.  Therefore  after  a  control 
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sequence  has  been  decoded,  the  control  signal  must  branch  to  indicate  to  the  M4  that  internal  operations 
may  be  resumed.  The  interlock  is  required  because  there  is  a  possibility  that  the  M4  might  be  able  to 
generate  a  control  signal  on  another  input  to  the  call  element  before  it  has  been  cleared  bv  the  return 
signal.  This  possibility  is  very  slight  because  the  M4  must  do  a  memory  operatioi.  before  another 
contiol  signal  could  Le  gein -'ated.  There  is  a  considerable  responsibility  placed  on  the  operation  of 
the  M4  in  orde’’  to  insure  the  proper  operation  of  these  concurrent  sequences. 

4.3.2  CONTROL  RETURN  TO  THE  M4 

Figure  10  shows  the  use  of  introl  returns.  Returning  control  must  gate  a  number  representing 
the  control  sequence  into  a  register.  Then  contiol  must  pass  to  the  M4  to  process  the  return.  The 
completion  signal  from  the  processing  operation  must  finally  rendc  .vous  with  the  start  of  the  particular 
control  sequence  because  the  M4  could  immediately  reactivate  the  same  external  control  sequence. 
Failure  to  do  this  may  mean  that  two  control  signals  could  be  acii.e  in  a  single  control  sequence;  an 
illegal  operation  in  macromodules.  The  dot  on  an  input  to  a  rendezvous  element  is  a  standard  notation 
to  indicate  the  input  is  preset  to  an  active  state.  An  interlock  is  shown  between  control  sequences 
1  and  2  indicating  that  they  may  be  concurrently  active.  Once  again  we  see  that  he  M4  is  responsible 
for  a  considerable  amount  of  control  information. 

4.4  IMPLEMENTATION  CONSIDERATIONS 

The  implementation  of  external  control  and  register  operations  has  been  shown  as  a  purely 
macromodular  implementation.  This  assumes  a  proper  maciomodular  interface  with  the  M4.  In  the 
non-macromodular  implementations  of  the  M4,  it  may  be  important  to  reduce  the  number  of  interface 
points  between  the  M4  and  externally  implemented  macromodular  functions.  A  possible  technique  is 
to  use  a  memory  to  centralize  the  actual  interface  connections.’^  The  resulting  changes  in  the.  designs 
shown  here  are  not  discussed  but  it  is  still  possible  to  use  these  general  ideas. 
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5.  CONCLUSION 


This  .eport  has  presented  a  unified  approach  to  the  design  and  use  of  macromodular  computer 
systems.  Central  to  ihe  concept  is  a  meta  machine  which  is  capable  of  routing  control  and  data  transfer 
operations  as  specified  by  a  description  of  a  macromodular  system  and  also  provides  ?  standard  interface 
for  externally  implemented  macromodular  functions.  Several  implementations  of  the  meta  macromodule 
machine  M4  have  been  discussed.  The  M4  is  also  capable  of  providing  general  programming  support  for 
a  macromodular  system. 

It  is  felt  that  the  >inified  approach  is  a  very  valuable  concept  which  permits  an  evolutionary  approach 
to  computer  design  by  allowing  small  incremental  changes  to  be  made  and  evaluated  before  they  become 
a  fixed  part  of  the  system.  Even  while  these  changes  are  being  made,  the  user  always  has  an  easily 
recoverable  working  system.  The  unified  approach  appears  to  be  a  very  useful  means  for  providing  a 
convenient  input  form  for  functional  simulation  of  digital  systems. 

For  the  user  who  is  not  oriented  toward  computer  hardware,  the  unified  approach  permits  the  use 
of  the  concept  of  designing  a  special  machine  which  may,  but  does  not  have  to,  be  built.  If  the  user 
chooses  not  to  build  the  machine,  he  still  is  able  to  do  a  very  efficient  interpretation  of  his  machine 
using  the  meta  machine.  If  he  does  decide  to  build  the  computer,  he  is  not  required  to  build  all  of  it. 
The  unified  approach  gives  the  software  oriented  user  a  fixed  target  for  compiler  development  by 
providing  ti.  capability  of  having  a  system  on  which  to  run  the  compi'e:  and  its  results. 

Finally,  and  probably  the  most  importaPi,  the  unified  apprcawn  permits  the  best  hardware-software 
trade-offs  to  be  made.  Note  that  many  parts  of  the  solution  can  be  expressed  in  a  high  level  language 
if  that  is  convenient.  It  is  important  to  note  that  the  hardware-software  balance  can  always  be  changed 
as  experience  with  a  system  grows. 

These  conclusions  represent  the  contribution  of  the  unified  approach  to  the  development  and  use 
of  macromodules.  Although  only  the  relationship  with  macromodules  has  been  discussed  in  this  report, 
it  seems  that  the  unified  approach  can  be  applied  to  other  restructurable  computer  systems.  It  is  after 
all,  primarily  a  way  of  •  king  about  a  problem  and  as  such  has  great  generality. 
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A  UNIFORM  AND  CONSISTENT  NOTATION  F;  *  DESCRIBING  A  MACROMODULAR  SYSTEM 

6.1.1  INTRODUCTION 

In  this  section  a  uniform  and  consistent  notation  is  discussed  which  may  be  used  to  describe  a 
macromodular  system  design.  Besides  being  capable  of  completely  describing  the  system,  the  nota''On 
is  convenient  to  use.  A  macromodular  system  is  completely  described  by  considering  two  separate 
aspects.  The  exact  definition  of  the  meaning,  or  semantics,  of  operation  is  determined  by  the  physical 
placement  of  the  modules.  This  placement  indicates  what  data  may  be  added  together,  what  data 
transfer  operations  may  take  place,  and  .all  the  other  considerations  of  meaning.  Second,  the  order  in 
which  these  operations  are  carried  out,  or  syntax  is  defined  by  the  routing  of  control  cables  %  'hich  link 
together  in  specified  sequences  the  various  operati  ns.  Notice  that  neither  one  of  these  alone  complete¬ 
ly  describes  a  system  and  both  have  distinct  functions.  The  method  of  notation  takes  advantage  of 
these  considerations. 

6.1.2  THE  C.\r^  PROCESSING  DESCRIPTION 

The  data  processing  operations,  or  semantics,  are  described  by  a  pictorial  diagram  which  corres¬ 
ponds  roughly  tc  the  actual  physical  placement  of  modules.  Because  the  width,  in  temis  of  multiples 
of  the  basic  macromodules,  is  quite  flexible,  the  a'-ual  width  of  operations  is  shown  by  drawing  short 
vertical  lines  between  modules  to  indicate  operations  of  mi''e  than  one  module  length.  The  area  above 
the  dotted  line  is  used  to  give  a  name  to  the  operat'  'hich  then  appears  in  the  control  sequence 
descriptions.  Additional  names  may  be  i.idicated  as  a'*e<r.atives  within  this  area  of  any  single  module. 
This  arbitrary  name  extends  for  the  full  width  of  the  defined  operation.  The  module  type  appears  in  a 
circle  in  the  lower  left  corner  of  each  box.  Module  type  info.mation  m?v  have  an  e  or  i  subscript  tc 
denote  an  externally  or  internally  implemented  function.  These  designations  are  subject  to  the  rules  on 
implementation.  For  example,  it  is  not  possible  to  have  an  internal  register  with  an  external  adder  on  it. 
The  area  below  the  dotted  line  is  used  to  describe  data  cable  inputs,  the  name  of  a  register,  or  other 
input  information.  Note  that  a  line  is  used  for  each  different  cable  input  so  some  modules  may  take  up 
more  space  in  the  picture  than  they  actually  do.  Fixed  parameiers  may  be  written  in  octal  in  place  of 
cable  input  names.  Figure  6.1.1  shows  a  typical  description. 

6.1.3  CONTROL  DESCRIPTION 

The  description  of  the  control  sequences,  oi  syntax,  consists  of  flowcharts.  Each  entry  consists 
of  the  name  of  an  operation  which  has  been  defined  in  the  data  processing  description.  Control  branch 
and  rendezvous  units  ate  shown  as  small  circles,  operations  as  rectangular  boxes,  decisions  as  ovals, 
and  subroutine  calls  as  trapezoids.  Figure  6.1.2  shows  a  typical  flow  chart  for  the  operations  defined 
in  the  previous  section. 

Notice  that  the  flowchart  contains  annotation  to  describe  external  and  internal  functions.  In  some 
sense  this  is  redundant  information  because  these  attributes  are  defined  by  the  data  proces  .  ,  module 
drawings.  However,  the  small  numbers  on  the  connecting  arcs  are  necessary  and  are  used  to  assign 
numbetj  to  control  exit  and  return  lines. 
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6.1.4  CONCLUSION 

The  above  notation  has  been  used  by  the  author  and  has  been  found  to  be  very  convenient.  Even 
though  the  notatijt.  is  complete,  it  is  not  felt  that  the  required  detail  is  a  drawback.  Because  the 
designer  is  committing  actual  expensive  hardware,  he  must  know  exactly  which  operations,  are  currently 
available.  The  number  of  flowcharts  requi.’ed  is  not  large  because  a  system  with  ?.  lev  hundred  oper¬ 
ations  in  it  represents  a  large  system,  whih‘.  the  same  number  of  machine  language  instaictions  would 
represent  only  a  very  s.-riall  program.  One  flowchart  entry  may  represent  several  actual  macromodules 
because  of  multiple  width  operations. 

The  ability  to  name  the  operation  in  the  semantic  description  and  then  use  it.  in  the  control  'low- 

charts  make  possible  flowcharts  which  arc  completely  annotated  yet  are  directly  related  to  the  definition 

of  the  operations.  This  is  an  extremely  important  aspect  of  the  desc.'iptive  notation  presented  here.  In 

% 

the  future  it  may  be  possible  to  name  groups  of  operations  and  therefore  introduce  a  macro  facility  into 
the  notation. 

After  using  this  descriptive  notation  for  a  while,  one  is  exUemely  unhapp.  to  be  required  to  render 
the  description  almost  completely  unintelligible  in  order  to  transform  it  to  a  machine  readable  torm.  A 
concerted  effort  must  be  taken  to  devise  a  method  of  introducing  the  descriptive  notation  into  a  computer 
in  a  more  direct  form. 
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APPENDIX  6.2 

CALCULATION  v  THE  RATIO  OF  SIMULATION 
TIME  CC  PARED  TO  ACTUAL  OPERATION  TIME 

6.2.1  INTRODUCTION 

In  this  appendix  an  approximate  ratio  is  derived  for  the  time  required  foi  simulation  of  macro- 
modular  operations  compareo  to  the  time  required  for  the  actual  .nacromodular  operations.  Because  of 
the  asynchronous  operatio>'  of  i.iacrornociules  these  calculations  yield  only  an  order  of  magnitude  ty^e 
vaUit  for  this  comparison.  The  calculations  indicate  that  an  order  of  magnitude  if  100  to  1  ’s  a  reason¬ 
able  va'ue  for  a  machine  which  is  ideally  suited  for  simulation  o*'  macromodules.  Of  course,  for 
simulation  cn  a  typical  digital  computer  the  ratio  is  likely  to  be  much  h'gher. 

6.2.2  THE  CALCULATION 
i:  2.2.1  THE  PROBLEM 

As  a  typical  macromodular  operation,  take  a  register  to  register  transfe  operation  operating  on 
36-bit  registers.  This  corresponds  to  three  register  macromodules  connected  to  foim  one  larger  register. 
The  .  i,tive  data  gate  on  the  destination  register  is  the  fourth  one  from  the  registei  in  the  stack  of  data 
gates.  Finally,  it  is  assumed  that  there  are  five  data  processing  modules  above  the  register.  These 
details  ate  important  because  operation  times  are  dependent  on  these  factors.  Although  formulas  can  be 
derived  for  timing  operations,  this  is  not  an  appropriate  place  for  presenting  this  information.’*  The  time 
for  this  operation  in  the  actual  macromodules  is  250  nanoseconds.’^  Experienced  intuition  is  the  only 
guide  for  describing  this  as  a  typical  operation. 

6.2.2.2  THE  SIMULATION  MACHINE 

Th\  machine  which  will  be  assumed  in  this  calculation,  is  ideally  suited  for  simulation  of  macro- 
modi ’es  in  that  it  follows  the  specification  of  '.he  meta  macromodule  machine.  This  means  thai  the 
machine  c^n  simulate  the  register  transfer  operation  with  only  one  instruction.  However,  beccuse  a 
basic  l2  bit  machine  is  postulated,  several  memory  refeiences  are  required  to  perform  the  operation. 
Out  calculations  therefore  involve  counting  only  memory  references.  One  nemory  reference  is  required 
to  access  tl  operation  code.  A  memory  reference  is  requireo  to  ge.  the  addresses  of  'he  memory 
locations  for  the  thiee  source  and  three  destination  registers.  Finally  three  words  of  data  must  be  read 
from  memory  anc  "'tored  into  three  other  memory  locations  Therefore,  thirteen  memory  references  a.e 
required  to  perform  the  operation  described  in  section  6.2.2. 1  If  a  memory  cycle  time  of  Iwo  micro¬ 
seconds  is  used,  the  total  tim'  for  simulation  of  this  operation  is  26  microseconds.  This  is  100  times 
the  250  nanoseconds  required  for  the  actua.  operation.  If  a  one  microsecond  memory  is  available, 
the  ratio  beco.mes  50  to 

6.2.3  CONCLUSION 

It  has  been  shown  that  a  ratio  of  100  to  i  for  functional  simulation  lime  compared  to  actu.il 
operation  time  is  realistic.  The  reader  should  be  cautioned  .nat  this  ratio  holds  only  foi  the  particular. 
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bul  realistic,  situatiims  tlescribed  here.  If  funciionai  simulation  is  to  be  a  realistic  design  aid  ratios 
of  this  order  are  required. 

Because  this  ratio  tan  easily  grow  by  decimal  orders  of  magnitude,  it  is  an  extremely  important 
factor  for  i,imiilat,!rs  1 1  be  aware  of.  Nc  matter  how  convenient  a  particular  simulation  tool  may  be,  if  a 
user  requires  several  hours  of  computet  time  to  simulate  a  few  .econds  of  real  lime,  the  tool  is  not  very 
iseful. 
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APPENDIX  6.3 
AN  EXAMPLE 


6.3.1  INTRODUCTION 

The  example,  which  is  part  rf  an  actual  investigation,  concerns  the  requirement  for  translating 
spherical  to  rectangular  coordinates.  The  following  equations  define  the  translation: 

X  =  p  sin  0  cos  6  (1) 

y  =  p  sin  0  sin  6  (2) 

z  =  p  cos  0  (3) 

The  existence  of  a  compiler  for  a  FORTRAN-ltke  language  to  the  M4  operations  is  assumed.  The 
example  will  show  the  evolution  of  the  coordinate  translation  from  a  completely  internal  version  to  one 
implemented  entirely  in  macromodules.  The  routine  finds  the  input  arguments  in  three  variables  called 
p,  0,  and  d.  The  output  of  the  routine  is  left  in  three  varia'^les  called  x,  y,  and  z. 

6.3.2  INITIAL  FORM 

Initially  the  coordinate  translation  is  to  be  specified  as  a  program  in  a  high'll  level  language. 

phi  -  phi  *  3.14/180,  I  translate  degree  arguments 
theta  =  theta  *  3.14  180;  I  into  radians 
X  rho  *  sin  (phi)  *  cos  (theta),  ^ 
y  =  rho  *  sin  (phi)  *  sin  (theta),  >  compute  x,  y,  z 
z  =  rho  *  cos  (phi);  ) 

The  language  is  almost  FORTRAN  and  the  execution  time  for  single  pr  cision, fixed  point  results  is 
estimated  to  be  approximately  500  microseconds  on  a  machine  with  a  two  microsecond  memory  cycle 
time.  The  sine  and  cosine  are  computed  by  the  standard,  built-in  trigonometric  subroutines. 

6.3.3  TABLE  LOOK-UP 

The  next  step  is  the  realization  that  because  the  angles  for  this  application  are  physically  measured 
with  values  known  <v.  only  t  Vi  degree,  the  trigonometric  functions  can  be  performed  by  simple  table 
look-up.  An  externally  implemented  table  look-up  routine  is  designed  and  called  by  simulated  macro- 
modular  call  elements.  Naturally  vl:*.  subroutine  could  be  marked  and  run  in  int"rnal  implementation 
for  debugging  purposes.  Figure  6.3.1  showst)^e  data  processing  module  layout  including  those  modules 
necessary  for  communication  with  the  M4.  Figure  6.3.2  is  the  control  network  flow  chart.  Note  that 
internal  functions  are  designed  which  operate  on  externally  implemented  registers. 

6.3.4  IMPLEMENT  TABLE  LOOK  UP  CALL  EXTERNALLY 

The  next  step  might  be  to  implement  the  subroutine  call  externally.  This  is  a  reasonable  step 
because  the  i.nternal  execution  of  the  call  and  return  takes  about  the  same  length  of  time  as  the  entire 
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TABLf  LOOK-UP  -  CONTROL 


Figure  6.3,2 
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table  look-up  operation.  Because  the  subroutine  is  called  from  three  places,  three  control  lines  in  each 
direction  between  the  M4  and  externally  implemented  functions  are  required.  The  data  processing 
structure  is  not  shown  because  it  is  almost  identical  to  Figure  6.3.1.  The  control  network  flow  chart 
is  shown  in  Figure  6. 3. 3. 

6.3.5  IMPLEMENT  PARALLELISM  WITH  MOST  CALCULATIONS  INTERNAL 

The  next  step  is  a  redesign  ba.sod  on  the  fac'  'hat  it  is  possible  to  use  some  concurrent  processing. 
It  is  possible  to  compute  a  sine  or  cosine  function  at  the  same  time  that  a  multiplication  's  being  done. 
Also,  there  is  a  common  subexpression  in  the  equations  for  x  and  y  which  only  needs  to  be  computed 
once.  Finally,  at  this  time  ve  do  not  wish  to  perform  the  multiplication  in  macromodules  but  do,  however 
want  to  shift  the  focus  so  that  the  coordinate  translation  is  essentially  controlled  by  the  externally 
implemented  functions.  Again  we  note  that  any  of  the  macromodular  functions  may  be  internally  imple- 
mcr.ted  by  the  M4.  Figure  6.3.4  shows  the  data  processing  modules  required,  excluding  most  of  those 
used  for  communication  with  the  M4,  Figure  6.3.5  gives  the  control  network  flowchart. 

6.3.6  ALL  OPERATIONS  IMPLEMENTED  EXTERNALLY  WITH  MACROMODULES 

Finally,  the  entire  coordinate  translation  is  implemented  externally  with  macromodules.  The 
execution  time  for  this  implementation  is  approximately  20  microseconds,  a  25  to  1  improvement  in 
speed  over  the  original  implementation.  For  this  description  a  multiply  macromodule  is  postulated  evi  p 
though  it  is  not  part  of  the  initial  set  of  modules.  Obviously,  the  multiply  function  can  be  implemente 
in  ierm.s  of  the  original  set  of  modules. 

The  completely  external  implementation  is  shown  in  Figures  6,3.6  and  6.3.7. 
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COMPLETE  EXTERNAL  IMPLEMENTATION  -  CONTROL 
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APPENDIX  6.4 

A  MACROMODULAR  META  MACROMODULE  MACHINE  (M6) 

6  4.1  INTRODUCTION 

This  appendix  summarizes  the  design  of  an  M6  which  has  been  referred  fo  in  the  body  of  the 
report.  T1  e  important  details  of  the  Me  communication  with  external  registers  and  control  were  pre¬ 
sented  in  the  body  of  the  report  and  are  not  repeated  here. 

There  is  one  primary  register,  which  is  36  bits  long,  where  all  the  macromodular  data  processing 
operations  take  place.  Because  of  the  greai  flexibility  with  which  data  cables  may  be  connected,  all 
of  the  simulated  data  cable  inputs  to  a  function  must  be  read  from  actual  or  simulated  registers  before 
the  operation  starts.  The  M6  uses  first-in  first-out  buffer  stacks  for  the  purpose  of  holding  these  operands. 

6.4.2  PROGRAM  AND  INSTRUCTION  FORMAT 

The  program  and  instriction  format  of  M6  is  analogous  to  a  stored  program  digital  computer.  In 
general  commands  are  stored  in  memory  which  describe  macromodular  operations  and  are  executed 
sequentially  except  for  decision-making  operations.  Along  with  each  command  is  stored  information 
regarding  the  simulated  registers  which  are  to  be  used  in  the  command.  The  operation  sequence  can  be 
broken  by  unconditional  o:  conditional  transfers  to  othe."  sequences  of  operations.  In  this  section  we 
assume  that  the  M6  has  a  4096  word  x  12  bit  memory.  Expansion  of  memory  capacity  can  be  handled 
by  some  type  of  paging  scheme.  The  M6  really  should  also  be  capable  of  executing  instructions  to 
perform  1  0  and  other  support  functions.  These  are  not  discussed  further  here. 

The  command  is  a  two  word  sequence  in  which  the  first  word  is  used  to  specify  the  macromodular 
operation  and  the  second  word  is  used  to  flag  options  on  the  command.  The  only  flagged  operation 
curienlly  specified  is  the  very  important  one  of  specifying  whether  or  not  control  is  to  remain  within  the 
ini’ta  machine  or  is  to  exit  to  externally  implemented  macromodular  functions.  Only  one  bit  is  needed  to 
specify  this  option;  however,  if  control  is  to  exit  at  this  point,  the  remaining  eleven  bits  are  used  to 
specify  the  external  control  sequence.  This  allows  2048  different  external  control  sequences  to  be 
specified. 

As  long  as  no  concurrent  operations  are  implemented,  external  control  f  ■■■.leration  and  return  is 
quite  simple.  However,  if  concurrent  operations  exist  and  some  of  them  are  external  and  some  are 
internal,  the  situation  becomes  more  complex.  It  is  required  that  all  externally  implemented  concunent 
operations  proceed  in  a  truly  concurrent  form  while  internal  operations  proceed  in  the  required  sequential 
form.  A  first-in  first-out  stack  is  used  to  remember  internal  control  sequences  w'hich  have  been  encoun¬ 
tered  but  not  executed.  Returning  external  control  signals  put  the  address  of  where  internal  operation 
is  to  resume  into  this  stack.  Thus,  as  internal  rendezvous  elements  are  encountered,  the  uncompleted 
sequences  are  executed  but  externa!  control  may  be  executed  in  true  concurrent  form. 

Data  refeiences  to  rea'  or  simulated  registers  consist  of  a  sequence  of  addresses  of  register 
specifications  preceded  by  an  integer  which  specifies  the  number  of  basiv.  12  bit  register  modules  in 
the  reference.  There  are  as  many  consecutive  sets  of  data  references  as  are  called  for  by  a  particular 
macrfimodular  f  iction.  For  example,  Jata  gates  and  registers  require  two  data  references  while  a 
comparator  requires  three.  The  following  forms  indicate  the  use  of  a  data  gate  operation  foi  both  12 
and  24  bit  data  references; 
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word  n'  data  gate 
n  ♦  1;  flag 

II  *  2  1 

n  +  2  source  register  srecification  address 

r  4:  1 

n  +  5:  deslimtion  register  specification  address 

24-bit 

word  n:  data  gate 
n  +  r.  flag 

n  +  2;  2 

p.  *  3:  source  register  specification  address  foi  bits  0-11 

n  +  4:  source  register  specification  address  for  bits  12-23 

n  ♦  5;  2 

n  6:  desti.'.-rtion  register  specification  address  for  bits  0-11 

li  7;  destination  register  specification  address  for  bits  12-23 

Register  specifications  consist  of  either  a  single  word  or  two  consecutive  words  in  the 
M6  memory.  The  first  word  contains  one  bit  which  specifies  whether  the  register  is  simulated 
ip  memory  or  exists  outside  the  meta  machine  implemented  as  an  actual  macromodular  register. 
If  this  is  the  ca;  the  remaining  11  bits  ate  used  to  specify  a  register  number.  Fiius  it  is 
possible  to  access  a  total  of  2048  externally  impicircnted  regis.eis.  If  .lie  register  is  simu¬ 
lated  within  memory,  the  first  specification  word  also  contains  a  bit  which  is  a  true  reflection, 
in  the  macromc'duli-;  sense,  of  the  overflow  condition  of  the  register.  The  remaining  ten  bits 
are  av.iilable  for  other,  fntu'e  uses.  Finally  ,thc  sect.  J  word  holds  the  contents  of  the 
simulated  register. 

Control  operations  in  M6  ire  analogous  to  those  in  stored  program  computers.  For  non- 
decision  operations  control  passes  tc  the  next  operation  specified  in  contiguous  memory 
locations.  A  location  register  is  used,  as  in  a  programmed  computer.  Decision  operations 
interrupt  the  consecutive  flow  of  control  for  all  possible  decision  outputs.  A  ‘.ransfer  of  control 
is  specified  by  a  12  bit  address  which  i.'dicates  the  start  of  a  nev  control  sequence.  I'his  is 
directly  analogous  to  branch  or  jump  instructions  in  a  stored  program  computer. 

6.4.:  UATA  OPERATIONS 

The  instruction  formats  of  all  macromoujles  ’vhici.  process  or  monitor  data  are  presented 
here.  Each  word  of  the  operation  is  not  s.  ecified  in  detail.  Specifically,  the  command  and 
flag  words  are  assumed  to  be  part  of  the  mnemonic  for  t('e  operation  and  the  details  of  the  data 
•references  arc  subsumed  in  the  notation:  operand),  cperand2,  etc.  Note  also  that  the  numerical 
code  for  each  operation  has  not  been  specified,  ’n  general,  the  irst  operand  specifies  a  c.  ble 
input,  and  the  second  operand  specifies  the  register  on  which  the  command  operates.  The 
parentheses  are  used  to  denote,  the  contents  of  the  register  specif. ed  by.  Thus,  (op  rand,) 
means  that  operand,  is  a  .'egister  specification  address  and  the  data  described  by  ih'jt  specifi¬ 
cation  are  used  in  the  operation. 
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DATA  GATE 

dg,  operand,,  operand2 
(operand,)  (operandj) 

ADDER 

ad,  operand,,  operand2 
(operand,)  +  (operand2)  •  (operand-.) 

SUBTRAC  r  CABLE 

subc,  operand,,  operand2 
(operandj)  -  (operand,)  (operand2) 

SUBTRACT  REGISTER 

subr,  operand,,  operand2 
'operand,)  -  (operand2)  -•  (operand2) 

OR 


or,  operand,,  operand2 
voperandi)  +  (operand2)  -•  (operand2) 

EXCLUSIVE  OR 

Xor, operand ,,  opeiand2 
(operand, )(+.(operand2)  -•  (operand2) 

AND 


and,  operand,,  operandj 
(operand,)  .  (operand2)  (operand2) 

WRITE  MEMORY 

wrm,  addicss  cf  memory  specification,  operand,,  operandj 

The  contents  of  the  register  specified  by  opi^rand,  are  used  as  the  address  at  which  to 
store  the  contents  of  the  register  specified  by  operandj.  The  memory  specification  consists 
of  ne  or  two  consecutive  words  which  give  the  address  in  the  memory  of  the  M4  which  corres¬ 
ponds  to  address  zero  of  the  simulated  memory.  Consecutive  12  bit  words  are  used  to  store 
the  data.  The  operation  does  not  pe'mit  writing  into  12  bit  fields  of  a  wider  memory  module, 
an  operation  currently  under  feasibility  study  by  the  designers  of  macromodules. 


READ  MEMORY 


rdm,  addr  of  memory  specification,  operand,,  operattdj 

The  contents  of  the  register  specified  by  operand,  are  used  as  an  address  whose  contents  are 
moved  into  the  register  specified  by  operand..  Th'*  other  details  of  the  operation  ate  specified  in  the 
in  the  previous  paragraph. 

SHIFT  LEFT 

shl,  operand,,  operand2 

(operand2)  is  shifted  left  one  bit  position.  The  left  most  bit  is  lost  and  the  vacated  bit  position 
is  filled  from  the  left  most  bit  of  (operand,). 

SHIFT  RIGHT 

sht,  operand,,  opetand2 

(opetandj)  is  shifted  right  one  bit  position.  The  right  most  bit  is  lost  and  the  vacated  bit  position 
is  filled  from  the  right  most  bit  of  (operand,). 

6.4.4  CONTROL  OPERATIONS 

This  section  specifies  the  macromodular  control  operation  commi.nds. 

COMPARATOR 

comj  irddk.'ss,,  add<fess2,  operand,^  operand2,  operand3 

The  contents  of  the  register  specified  by  operand3  are  compared  to  the  contents  of  the  register 
specified  by  0|.erand,  using  the  contents  of  the  register  specified  by  operand2  as  a  mask.  If  the  com¬ 
parison  is  false,  the  next  command  is  taken  from  address,.  If  the  comparison  is  true,  the  next  command 
is  taken  from  address^.  No  data  are  changed  by  this  operation. 

TEST  OVERFLOW 

tov,  operand,,  address,,  address2 

If  the  o\  ;.now  indicator  of  the  register  specified  oy  operand,  is  on,  the  next  command  is  taken 
from  address,,  oi.  J'fwise  the  next  command  is  taken  from  addtess2. 

TRANSFER  OF  CONTROL 

to,  address. 

Control  is  unconditionally  transferred  to  the  command  at  address,. 

CALL  ELEMENT 


cle,  address,,  address2 
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Control  is  transferred  to  the  first  command  of  the  macromodular  subroutine  which  starts  at 
address2.  The  command  at  address^  must  be  a  transfer  of  control  w’..  ch  is  used  to  return  control  to 
the  place  from  which  the  subroutine  was  called. 

DECISION  CALL  ELEMENT 

dee,  address^,  address2,  addre‘:s3,  address4,  address5 

Control  is  transferred  to  the  tv  return  subroutine  beginning  at  address5.  Address)  is  the  address 
of  the  command  which  follows  the  call  for  one  return  of  the  subroutine.  Address^  is  the  address  of  the 
transfer  of  control  at  the  end  of  the  subroutine  for  this  same  return.  Address^  and  address^  have  the 
same  functions  as  address ^  and  address2  for  the  other  return  from  the  subroutine. 

BRANCH  UNIT 

bru,  address^,  address2 

The  branch  unit  initiates  the  two  concurrent  sequences  which  start  at  address^  and  address2 
Externally  implemented  sequences  are  initiated  immediately  while  internal  sequences  are  ini  iated  in 
turn  with  more  than  one  stored  in  the  control  stack. 

RENDEZVOUS  UNIT 

rvu  1,  rvu  r,  mark 

The  rendezvous  unit  terminates  concurrent  sequences.  Thei  'e  two  inputs,  left  and  right,  which 
must  be  specified  in  that  order.  The  mark  word  is  used  to  indicate  whether  or  not  the  rendezvous  has 
had  both  inputs  activated.  If  control  has  been  activated  at  both  inputs,  the  command  immediately 
following  is  executed.  If  only  one  input  has  been  activated,  control  must  pass  to  a  sequence  whose 
starting  address  has  been  stored  in  the  control  stack. 

DECODER 

dec,  operand,,  ope.rand2,  addressj,  addresS),...,  address7 

The  contents  of  the  register  specified  by  operand)  used  a':  a  mask  which  indicates  three  con¬ 
tiguous  bits  of  the  register  specified  by  operandj  to  be  decoded.  Control  passes  to  address^,  address,,..., 
depending  on  the  octal  value  of  the  three  decoded  bits. 

INTERLOCK 

Not  simulated. 

6.4.5  EXAMPLES  OF  THE  M6  DESIGN 

Although  it  is  difficult  to  present  some  of  the  design  of  the  M6  without  presenting  the  detailed 
design  in  its  entirety,  this  section  will  discuss,  in  general  terms,  the  design  of  a  few  selected  areas 
of  the  M6. 
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6.4.5.1  DATA  FETCH 

An  important  operation  in  the  M6  is  the  tetching  data  which  is  to  be  u'.ed  as  a  cablo  input  to  a 
simulated  operation.  The  data  may  consist  of  any  numbei  of  register  segments  up  to  the  capacity  of  the 
buffet  stacks  mentioned  in  6.4.1.  There  is  also  the  requirement  that  any  of  the  register  segments  may  be 
implemented  externally.  The  design  is  shown  as  a  general  flowchart  in  Figure  6.4.1. 

6.4.5.2  AND  OPERATION 

The  AND  operation  represents  that  class  of  macromodular  data  processing  functions  which  can  be 
performed  by  simple  iteration  of  segments.  Each  segment  is  complete  by  itself  and  there  is  no  need  to 
know  information  from  any  other  segment.  The  design  of  the  AND  is  presented  in  Fifjure  6.4.2.  Notice 
that  all  segments  for  the  cable  input  are  fetched  and  stored  into  a  buffet  stack.  Then  each  segment  for 
the  register  operand  is  fetched,  the  next  cable  segment  read  from  the  stack,  the  operation  performed,  and 
the  result  restored  to  the  proper  segment.  The  operations  concerned  with  fetching  and  restcting  the 
register  operand  segments  contain  commands  similar  to  those  discussed  in  6.4.S.I. 

6.4.5.3  ADD  OPERATION 

The  ADD  operation  represents  a  class  of  operations  in  which  each  segment  is  dependent  on  other 
segments.  In  this  case,  provision  must  be  made  to  propagate  the  carry  generated  in  each  segment  on 
to  the  next  segment.  This  is  done  by  having  registers  to  the  left  and  right  of  the  tegister  where  the  ADD 
takes  place.  The  carry  is  generated  into  the  leftmost  register  which  is  then  moved  to  the  most  signifi¬ 
cant  bit  position  of  the  rightmost  register.  The  ADD  operation  then  adds  zero  to  the  leftmost  register, 
the  cable  segment  to  the  center  register,  and  a  constant  with  a  one  in  the  most  significant  bit  position 
to  the  rightmost  register.  The  overflow  indicator  is  cleared  fo:  all  bit  the  most  significant  segment.  The 
design  is  described  by  tk^  flowchart  in  Figure  6.4.3. 

6.4.5  4  COMPARE  OPERATION 

The  COMPARE  operation  represents  those  operations  which  cause  a  transfer  of  control.  This  is 
simply  a  matter  of  moving  one  of  two  possible  addresses  to  the  P  register  or  location  counter.  The 
COMPARE  operation  requires  two  cable  inputs.  Because  no  data  is  changed,  there  is  no  need  to  restore 
any  segments.  Finally,  if  the  comparison  fails  on  any  segments  except  the  last,  the  remaining  segments 
are  not  checked  but  there  is  some  overhead  required  to  clear  the  previously  filled  buffer  stacks.  The 
design  of  the  COMPARE  operation  is  shov  .i  in  Figure  6.4.4. 


GET  NUMBER  OF  SEGMENTS 


DATA  FETCH  FOR  SIMULATED  OPERATION 


Figure  6.4.1 


THE  AND  OPERATION 


Figu'-e  6.4.2 
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THE  ADD  OPERATION 


Figure  6.4.3 
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INITIALIZE  COMPARE  OPERATION 


FETCH  CABLE^  SEGMENTS 
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